Use and generation of a session key in a secure socket layer connection

ABSTRACT

The invention describes a method and system for verifying the link between a public key and a server&#39;s identity without relying on the trustworthiness of the root certificate of the server&#39;s certificate chain. The system establishes a secure socket layer type connection between a client and a server. The client and the server create an identical authentication key using a shared secret known to the server and the client. Next, the server transmits a first encrypted message to the client, wherein the first encrypted message includes the server&#39;s public key encrypted with the authentication key. Then, the client decrypts the first encrypted message and verifies the correctness of that message including comparing the public key included in the decrypted first encrypted message to the public key transmitted during the set-up of the secure socket layer type connection to authenticate the client.

PRIORITY

The present application is a continuation application of applicationSer. No. 10/135,163 filed Apr. 30, 2002, which claims the benefit ofpriority under 35 U.S.C. .§.119(e) to U.S. Provisional PatentApplication entitled “Use and Generation of a Session Key in a SecureSocket Layer Connection”, Ser. No. 60/287,858, filed on May 1, 2001,which application is incorporated herein by reference.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is related to the following United Statespatents and patent applications, which patent/applications are assignedto the owner of the present invention, and which patents/applicationsare incorporated by reference herein in their entirety:

U.S. patent application Ser. No. 09/789,197, entitled “FieldProgrammable Smart Card Terminal and Token Device”, filed on Feb. 20,2001, currently pending;

U.S. Pat. No. 4,599,489, entitled “Solid State Key for ControllingAccess to Computer Software”, filed on Feb. 22, 1984, issued on Jul. 8,1986;

U.S. Pat. No. 4,609,777, entitled “Solid State Key for ControllingAccess to Computer Software”, filed on Dec. 23, 1985, issued on Sep. 2,1986; and

U.S. Pat. No. 4,819,267, entitled “Solid State Key for ControllingAccess to Computer Systems and to Computer Software and/or for SecureCommunications, filed on Jun. 9, 1987, issued on Apr. 4, 1989.

FIELD OF THE INVENTION

The invention relates generally to establishing secure connections overa network, and more particularly to establishing a secure socket layertype connection over a digital public network.

BACKGROUND

Extended development and public acceptance have made electronic commerceand distributed transactions over public networks widespread. As shownin FIG. 1, many of these transactions involve a client device 110, suchas a personal computer, accessing and communicating with a server 120.The connection between the client 110 and the server 120 maybe used toexchange confidential information or enable the server to providerestricted or secured access. As a result, the need for security intransactions between a client and a server occurring over a digitalconnection on a network has become widespread as well. Therefore, inmany cases, the connection between the client 110 and the server 120 isan encrypted and mutually authenticated connection 130.

The prior art includes several methods that attempt to resolve this needfor security that requires mutual authentication and encryptedcommunication between the server and client. One method utilizes asymmetrical encryption algorithm based on a shared secret. In general, ashared secret is known to both the client and the server. However, ashared secret may sometimes also be possessed by a trusted third party.In general, a shared secret is not known to or easily determined by thepublic at large. The shared secret is used to derive an encryption key.The encryption key is then used to encrypt communication between theserver and the client using a symmetrical encryption algorithm. Thesymmetrical encryption algorithm achieves confidentiality because theencrypted messages can't be read without knowing the shared secret. Themethod achieves authentication in that only a participant to theconnection who possesses the shared secret may properly encrypt anddecrypt messages with another participant. Thus, if a participant canread and generate a message or connection request that is encrypted, theparty must possess the secret and is deemed authenticated. For practicalreasons, the shared secret often originates from the client side by aphysical person operating the client side (e.g. by typing in apassword). For ergonomic reasons, the size of the shared secret (e.g.the number of characters in a password) is therefore quite limited. As aresult, the cryptographic strength of the symmetric encryption keyderived from that shared secret is also rather limited.

Another method used by previous systems involves an asymmetriccryptographic algorithm and public key infrastructure (PKI) certificatesfor the server and the client. This method does not utilize a sharedsecret known to both ends of a connection before setting up theconnection. Rather, a client and a server exchange certificates whenthey establish a connection. The client and server then authenticate oneanother by validating each other's certificates. Next, dynamicallygenerated random data is exchanged by the client and server using thepublic keys certified by each other's certificates. Both the client andthe server use this dynamically generated data to compute separate butidentical symmetric encryption key. This symmetric encryption key isthen used to encrypt further communication between the client and theserver and thereby provide confidentiality. In practice, it may beimpractical to provide clients with certificates. As a result, sometimesonly the server has a certificate to be validated. In this case, theserver certificate is sufficient to authenticate the server and toestablish the symmetric encryption key that provides confidentiality.Another method must be used to authenticate the client. For example, theclient may provide proof to the server that it possesses a shared secretknown only to the server and the client (e.g. the client might send theserver a password). As mentioned above, the server end in a securesocket layer connection is authenticated by validating or verifying theserver's certificate. The server certificate includes a digitalsignature generated by a certification authority (CA) linking theserver's public key to the server's identity. The public key of the CAmay then be certified by another higher-level CA. In theory, an entirehierarchy or chain of certificates may require verification. Regardlessof the number of levels in a server's certificate chain, the client musthave the public key of the highest level or root CA to be able tovalidate the entire chain. Thus, the security of this method depends onthe trustworthiness of the root's public key.

There are several steps in preparing a PKI certificate. First the datato be signed is assembled. This data includes the public key and dataidentifying the entity associated with that public key. This data may beconsidered a message. Next a message digest is created and then themessage digest is encrypted. The message digest is a has of the messageor the set of data to be signed. The encrypted message digest is thesignature.

In practice, many client systems and network browsers have an extensivelist of certificate roots that the client “trusts.” It is usually notdifficult to convince a user to add additional certificate roots totheir list of trusted roots. Thus, a user may unknowingly add a taintedor false certificate root by an illegitimate CA. This false root mayhave been used by a dishonest entity to generate a certificate for anillegitimate server that poses as a legitimate server. In this way, adishonest entity may lead a client to make a connection with theillegitimate server and unknowingly provide sensitive information suchas the user's password to the legitimate server.

For purposes of illustration, one may consider a bank operating awebsite that allows bank customers to consult their accounts and performfinancial transactions online. Only the rightful owner of an accountshould have access to their account. Therefore, the bank might requireits customers to authenticate themselves by entering a password whenaccessing the site. To protect the confidentiality of informationexchanged between the client and the bank's website such as a userpassword, clients connect to the bank's website using the SSL protocol.A entity who wants to compromise the account of a legitimate bankcustomer could mount a man-in-the-middle. To do so, the entity could setup a website that mimics the legitimate bank website. The entitygenerates a certificate for the fraudulent website with a boguscertification authority. The entity tricks the legitimate customer intoadding the root certificate of the bogus CA to his list of trustedroots. If the legitimate customer now connects to the fraudulentwebsite, the legitimate customer will think it's the legitimate bankwebsite and enter a password. The entity has now obtained a validpassword and can access the real bank website posing as the legitimateuser to e.g. transfer money from the legitimate user's account to theentity's account. Thus, relying on a technique that requires a client totrust the public key of the root CA of a server's SSL certificate tovalidate the authenticity of that server may reduce the security levelof a secure socket layer connection and jeopardize server security.

What is therefore needed is away to increase the security of a securesocket layer connection. A client system should be able to verify thevalidity of a server's certificate or validate the link between theserver's public key and its claimed identity without the client systemhaving to trust the root CA or some intermediate CA of the server'scertificate chain.

SUMMARY OF THE INVENTION

The invention satisfies the shortcomings of the prior art by providing amethod and system for verifying the link between a public key and aserver's identity as claimed in the server's certificate without relyingon the trustworthiness of the root certificate of the server'scertificate chain. A secure socket layer type connection is establishedbetween a client and a server. While establishing the connection, theserver transmits the server's certificate information to the client.Next, information is sent from the client to the server. Then, theclient and the server independently create identical authentication keysby utilizing a shared secret known to the server and the client. Next,the server transmits a first encrypted message to the client over thesecure socket layer connection, wherein the first encrypted message isencrypted with the server authentication key and wherein the correctnessof the contents of the first message can be verified by the client.Then, the client decrypts the first encrypted message and validates thedecrypted first message thus authenticating the server. The client thentransmits a second encrypted message to the server, wherein the secondencrypted message is encrypted with the client authentication key andwherein the correctness of the contents of the second message can beverified by the server. Finally, the server decrypts the secondencrypted message and validates the decrypted second message thusauthenticating the client. In one embodiment, the first encryptedmessage sent by the server to the client contains the server'scertificate or public key that was used during the set-up of the securesocket layer type connection. In one embodiment, the shared secret usedto create the authentication key may be the response of a strongauthentication token. In this embodiment, the strong authenticationtoken maybe a challenge-response, event, internal counter-based ortime-based token, or any combination of these three strongauthentication token variants.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a illustration of a server client connection requiring asecured mutually authenticating connection in accordance with the priorart;

FIG. 2 is an illustration of a method for mutual authentication of anSSL connection in accordance with one embodiment of the presentinvention;

FIG. 3 is an illustration of a method for mutual authentication of anSSL connection in accordance with one embodiment of the presentinvention;

FIG. 4 is an illustration of a method for mutual authentication of anSSL connection, in accordance with one embodiment of the presentinvention; and

FIG. 5 is an illustration of a method for an authentication keygeneration process in accordance with one embodiment of the presentinvention.

DETAILED DESCRIPTION

The present invention solves the problems of prior systems by using asecret to verify the link between a public key and a server's identityas claimed in the server's certificate without relying on thetrustworthiness of the root certificate of the server's certificatechain. The invention takes the advantages of an SSL type connectionwithout relying on the root certificate needed to verify the server'sidentity. This is achieved using a symmetric encryption authenticationkey that the client and server generate independently from each other.The authentication key is used by the server to encrypt the server'spublic key or certificate that was used to set-up the SSL connection.Thus, the present invention achieves mutual authentication andencryption without depending on the trustworthiness of the servercertificate.

One method for establishing a secure connection between a client andserver involves using public key infrastructure (PKI) certificates forthe server and the client. The first step in this method includes aclient and a server exchanging certificates as they establish aconnection. The client and server may validate each other's certificatesto authenticate one another. However, in some instances, the client maynot provide a certificate. Next, dynamically generated random data isexchanged by the client and server using an asymmetric cryptographicalgorithm and the public keys certified by the client and server (eachby their own cert) certificates. Both the client and the server use thisdynamically generated data to compute identical symmetric encryptionkeys. This symmetric encryption key uses asymmetric encryption algorithmto encrypt all further communication during the connection between theclient and the server. A secure socket layer connection or just a secureconnection, as used herein shall include all types of connections thatare established using the certificate-based method discussed above.Examples of such connections include a secure socket layer (SSL)connection, a transaction layer security (TLS) connections, a wirelessTLS (WTLS) connection, an IP secure (IPSEC) connections.

In one embodiment of the present invention, two types of encryption areoccurring. The first level of encryption involves the encryptionprovided by the SSL connection. Messages sent over an SSL connection areencrypted. The second level of encryption involves the encryptionperformed by an authentication key. The authentication key is used toencrypt and decrypt messages to ensure that a client or server is who itrepresents itself to be. Unless otherwise specified, references toencryption herein are intended to pertain to the encryption performed byan authentication key.

A method 200 for establishing a server connection between the server andthe client in accordance with one embodiment of the present invention isshown in FIG. 2. In method 200, a client and server establish an SSLconnection in step 201. This SSL connection may be established with orwithout using a client certificate. While the SSL connection is beingestablished, the client receives the server's certificate. All furthercommunication between client and server occurs through this SSLconnection. In one embodiment, the result of the verification of theserver' certificate chain may be ignored.

Next, the authentication key to be used for mutually authenticating theserver and the client is created. First, the client and server exchangesome information in step 202. Then, the client and server each use thesame shared secret to independently compute a symmetric encryption keyin steps 203 and 204. This symmetric encryption key is theauthentication key. A shared secret as used herein is generally definedas a secret possessed by the client and the server. In one embodiment, athird party such as a certificate authority may possess the secret.However, a secret known to a third party is still considered secret fromthe public at large. In one embodiment, the shared secret is nottransferred between the server and the client.

Next, the client and server are both authenticated. First, the serverencrypts server authentication information in step 205. The serverconstructs this server authentication information so the client mayverify its correctness. The server then encrypts the serverauthentication information with the authentication key generated in theprevious step and transmits the encrypted server authenticationinformation to the client in step 206. By successfully decrypting thisencrypted server authentication information and verifying itscorrectness in step 207, the client authenticates the server end of theSSL connection and establishes the trustworthiness of the SSLconnection. Next, the client encrypts client authentication informationin step 208 with the same authentication key generated in step 203 andsends the encrypted client authentication information to the server instep 209. The server then decrypts the encrypted client authenticationinformation received from the client and verifies its correctness instep 210. By successfully decrypting and verifying the encrypted clientauthentication information, the server authenticates the client. Theclient authentication information can include the username and/or partof the information exchanged between client and server earlier on. Theauthentication key can be used to encrypt any further communicationbetween the server and the client in addition to the encryption alreadyprovided by the SSL connection.

FIG. 3 illustrates a method for establishing a secure connection betweena client and a server in another embodiment of the present invention. InFIG. 3, the server authentication information includes the server'spublic key that is certified previously by the SSL server certificate.Thus, verifying the correctness of the server authentication informationby the client includes verifying that the public key included in theserver authentication information is the same as the public keycertified by the SSL server certificate. The advantage of thisembodiment is that the server's SSL certificate has been authenticatedin a way which does not rely on using the public key of thecertification authority that signed the SSL server certificate. The SSLconnection can now be considered to be a secure, mutually authenticatedconnection that provides integrity and confidentiality, without theclient side having to rely on the trustworthiness of the rootcertificate that holds the key of the certification authority thatsigned the SSL server certificate and has been stored on the client.

Method 300 of FIG. 3 begins when the server and client establish asecure socket layer type connection in step 301. This step is similar tothe step of 201 in FIG. 2 except that the server sends its certificateto the client. The client then stores the certificate in step 302. Oncethe connection is established, all communication between the client andserver will occur through this connection.

Next, the server and client compute authentication keys. First, theclient and server exchange information in step 303. Then, the client andserver each use the same shared secret to independently compute asymmetric encryption key in steps 304 and 305. This symmetric encryptionkey is the authentication key. Next, the server encrypts the servercertificate using the symmetric encryption key in step 306 and transmitsthe encrypted server certificate to the client in step 307. The clientcompares the stored server certificate from step 302 to the encryptedserver certificate sent in step 308 to authenticate the server. Theclient then encrypts client authentication information in step 309. Theencrypted client authentication information is then sent to the serverfrom the client in step 310. The server then decrypts the clientauthentication information to authenticate the client in step 311.

In another embodiment of the present invention, the entire SSL servercertificate maybe included in the server authentication information instep 301. Verifying the correctness of the server authenticationinformation by the client in step 308 then includes verifying that thecertificate included in the server authentication information is thesame as the SSL server certificate received during the set-up of the SSLconnection in step 301.

In one embodiment of the present invention, the shared secret used bythe client and the server to generate the authentication key is theoutput of a strong authentication token (SAT). In a preferred embodimentof the invention, the output of the token is the dynamic passwordgenerated by the token. In this embodiment, the output of a SAT isprovided to both the client and the server. The client and servergenerate an authentication key using the SAT output. The SAT is nottransmitted between the client and the server before generating anauthentication key.

In one embodiment of the present invention, the SAT maybe achallenge-response token. In this embodiment, the output of the SAT mayrely on a challenge to generate a response. If a strong authenticationtoken requires a challenge from the server to generate a dynamicpassword, the server side of the SSL connection sends this challenge tothe client side of the SSL connection. The client and server will bothindependently generate a separate but identical response to thechallenge. The SAT response is then considered the shared secret betweenthe server and client and is used to generate the authentication key.

In another embodiment, the token may be a time-based SAT. Thisembodiment of a SAT may introduce synchronization issues to generatingan authentication key. In one embodiment where strong authenticationtokens are based on an internal real-time clock and/or an event such asan internal counter, the server may allow a limited set of possible SATresponses rather than one single SAT response. One reason for allowingmultiple SAT responses is to overcome synchronization issues. If astrong authentication token is time based, the server may not be capableof knowing exactly which value of the time the SAT has used to generateits response. This is because the internal clock of the SAT mightslightly drift with respect to the server's clock and because the userinteraction with the SAT always takes some varying unpredictable time.Similarly, if a strong authentication token is event based, the serveris often not capable of knowing exactly which value of the event counterthe SAT has used to generate its response. This is because it maybepossible that the SAT has generated a response that incremented acounter but didn't reach the server. Thus, the server would not be awarethat the event counter has been increased. To overcome thesynchronization problems in case of a time or event based SAT, theserver may allow a certain number of possible responses rather than asingle response. In one embodiment of the present invention, the numberof possible responses is relatively small. In the case of a time basedSAT, the server will use a window of time around the current time of itsreal-time clock and will allow multiple responses that can be generatedon the basis of time values in that window. Similarly, in the case of anevent based token the server will allow multiple responses that can begenerated on the basis of the current value of the server's counter anda limited number of consecutive counter values.

In one embodiment, to account for more than one valid response, theserver should allow more than one authentication key. However, since theserver first sends data to the client encrypted with the authenticationkey, the server should already know which of the possible authenticationkeys to use because the client only has one authentication key. Toenable the server to figure out which key of the set of possibleauthentication keys is the one being used by the client, asynchronization phase may be implemented.

FIG. 4 illustrates a method 400 for using a SAT to generate anauthentication key. The method 400 begins when the client and server setup an SSL connection in operation 401, with or without clientauthentication. While the connection is established, the server sendsthe server certificate to the client. The client obtains and stores theserver's certificate in operation 402. Once the connection isestablished, all further communication between client and server happenthrough this SSL connection.

Next, the authentication key is established as represented by steps 403and 404. In operation 403, the client sends information to the server.In one embodiment of the invention, the information is the username orother client authentication information identifying the user at theclient end. Next, the server and the client exchange some data that willbe used in calculating the authentication key in step 404. In oneembodiment of the present invention, the data exchanged are random seedscreated independently by the client and server. Next, if the SAT is achallenge-response SAT, the server sends a challenge to the client inoperation 405. Then, in operation 406 and 407 the client and serverindependently generate an identical symmetric encryption key using theresponse of the SAT and the data exchanged in the operation 404. Thissymmetric encryption key is the authentication key. Next, if the SAT isa time-based or event-based SAT, the server sends a synchronizationchallenge to the client in step 408. Then, the client encrypts thissynchronization challenge with the authentication key it has computed atstep 409. The client then sends the encrypted synchronization challengeback to the server in step 410.

The server then determines what authentication key to use instep 411. Inone embodiment, the server computes several acceptable SAT responsesusing information that may include the SAT challenge, the value of itsclock and the current value of the event counter. In one embodiment, theserver computes all the acceptable SAT responses. Then, based on theacceptable SAT responses computed and the data exchanged, the servercomputes a set of candidate authentication keys in operation.

In one embodiment, the server may decrypt the encrypted synchronizationchallenge it received from the client with each of the authenticationkeys that are allowed on the basis of its clock or event counter in step410. The key from the set of allowed keys that successfully decrypts theencrypted synchronization challenge is the key that will be used by theserver for authentication purposes.

Next, the client and server are authenticated. First, in operation 412the server encrypts the certificate that it has sent to the clientduring the set-up of the SSL connection with its authentication key. Theserver sends this encrypted certificate to the client in operation 413.Then, in operation 414, the client decrypts the certificate receivedfrom the server and compares it to the certificate received from theclient in the set-up of the SSL connection. Upon successfully decryptingof the encrypted server certificate and verifying it is the samecertificate that the client has obtained during the set-up of the SSLconnection, the client authenticates the server end of the SSLconnection and establishes the trustworthiness of the SSL connection.Next, in step 415 the client encrypts the username or other clientauthentication information sent to the server in step 403 with the sameauthentication key. The client sends this encrypted information to theserver in operations 416. The server then decrypts the information andcompares it to the information received from the client in step 417.Upon successfully decrypting the encrypted username or other informationpreviously received, the server authenticates the client. The SSLconnection can now be considered to be a secure, mutually authenticatedconnection that provides integrity and confidentiality, without relyingon the trustworthiness of the root certificate that has been stored onthe client. The authentication key can be used to encrypt any furthercommunication between the server and the client on top of the encryptionalready offered by the SSL connection.

FIG. 5 is a flow chart of a process 500 showing a key generationalgorithm based on the dynamic password of a challenge-response token inaccordance with one embodiment of the present invention. First, inoperations 501 and 502, the client and server exchange random seeds. Inone embodiment, the seeds are 256 bits in length are processed by boththe client and the server in a similar fashion. The seeds are thencombined in an operation 503. In one embodiment, the random seeds arecombined using an XOR function. If the token is a challenge-responsetoken the server will also provide the client with a challenge for thetoken. Next, the initial generation vector is created. First, the username which is known to the both the server and the client at the time ofthe session key generation is repeated to yield a string of 128 bits inoperation 504. A challenge issued by a server and known to both theserver and the client is then repeated to yield a string of 128 bits inoperation 506. Next, the first 128 bits of the combined random seeds andthe expanded user name and the expanded challenge are then combined toyield the Initial Generation Vector in operation 507. In one embodimentof the present invention, the elements are all combined using an XORfunction.

Next, the generation key is created. First, the response to thechallenge is repeated to yield a string of 128 bits in operation 509.The response is independently generated by both the server and theclient.

Then, the last 128 bits of the combined seeds and the expanded responseare combined to yield the Generating Key. In one embodiment, theelements are combined using an XOR function.

Then, in operation 511, using the generating key as a symmetrical blockcypher key, the symmetrical block cipher algorithm is applied X numberof times on the Initial Generation Vector with the output of round Nserving as the input to round N+1, where X is a fixed number known inadvance by both client and server such that the described calculationtakes something between 10 and 100 milliseconds on a typical client.Finally, the resulting 128 bits of this calculation are theAuthentication Key in operation 512. In one embodiment the symmetricalblock cipher algorithm is the 3 DES algorithm. In another embodiment thesymmetrical block cipher algorithm is the AES algorithm.

The present invention solves the problems of prior systems by using asecret to verify the link between a public key and a server's identityas claimed in the server's certificate without relying on thetrustworthiness of the root certificate of the server's certificatechain. The invention takes the advantages of an SSL type connectionwithout relying on the root certificate needed to verify the server'sidentity. This is achieved using a symmetric encryption authenticationkey that the client and server generate independently from each other.The authentication key is used by the server to encrypt the server'spublic key or certificate that was used to set-up the SSL connection.Thus, the present invention achieves mutual authentication andencryption without depending on the trustworthiness of the servercertificate.

Other features, aspects and objects of the invention can be obtainedfrom a review of the figures and the claims. It is to be understood thatother embodiments of the invention can be developed and fall within thespirit and scope of the invention and claims.

The foregoing description of preferred embodiments of the presentinvention has been provided for the purposes of illustration anddescription. It is not intended to be exhaustive or to limit theinvention to the precise forms disclosed. Obviously, many modificationsand variations will be apparent to the practitioner skilled in the art.The embodiments were chosen and described in order to best explain theprinciples of the invention and its practical application, therebyenabling others skilled in the art to understand the invention forvarious embodiments and with various modifications that are suited tothe particular use contemplated. It is intended that the scope of theinvention be defined by the following claims and their equivalence.

1. A method for establishing a secure connection and authenticating aserver in connections formed with PKI procedures, wherein a serverpublic key, obtained from the server by a client, is used withasymmetric cryptography to establish a symmetric session key forencryption of communications with symmetric cryptography during theconnection, said method offering an alternative for authenticating theserver public key, and comprising: generating a server authenticationkey by the server, transmitting said server public key by the server tothe client in clear text form; generating a client authentication key bythe client, the server authentication key and the client authenticationkey being identical to each other as both are generated using a commonsecret; generating server authentication information from data derivedfrom the server public key and processed with a symmetric cryptographicalgorithm and the server authentication key, sending said serverauthentication information to the client, verifying the serverauthentication information at the client in order to authenticate theserver public key, said verifying using the client authentication key todetermine that the server authentication information is based on saidserver authentication key and the server public key used in establishingthe secure connection and received from the server.
 2. A method asrecited in claim 1 wherein: the server authentication key is used forencrypting the server authentication information with a symmetricencryption algorithm; and which further includes: decrypting, at theclient, the received server authentication information with the clientauthentication key and a symmetric decryption algorithm, and whereinsaid verifying implements verifying the correctness of the serverauthentication information at the client by comparing the decryptedserver authentication information with the server public key used inestablishing the secure connection and received from the server.
 3. Themethod of claim 2 wherein the server authentication information includesa server certificate.
 4. The method of claim 2 wherein the secureconnection includes an SSL connection.
 5. The method of claim 2 whereinthe secure connection includes an WTLS connection.
 6. The method ofclaim 2 wherein the secure connection includes an IPSEC connection. 7.The method of claim 2 wherein the secure connection includes a TLSconnection.
 8. The method of claim 2 wherein the secret is generated bya strong authentication token.
 9. The method as recited in claim 2 whichfurther includes: sending client information to the server toauthenticate the client, the client information encrypted by the clientusing the client authentication key and decrypted by the server usingthe server authentication key, the correctness of the client informationverified by the server.
 10. The method of claim 2 wherein the serverauthentication information includes the server public key.
 11. Themethod of claim 2 wherein the server authentication information includesdata derived from the server public key.
 12. The method of claim 8wherein the strong authentication token is a challenge response token,wherein generating an authentication key by both the server and theclient includes: sending a challenge from a server to the strongauthentication token; generating a first strong authentication tokenresponse to the challenge at the client; generating a second strongauthentication token response to the challenge at the server, the firstresponse identical to the second response when the secret is common tothe client and server; deriving a client authentication key by theclient from the first strong authentication token response; deriving aserver authentication key by the server from the second strongauthentication token response.
 13. A method for authenticating a serverpublic key and establishing a secure connection between a client and aserver, the connection formed with PKI procedures and including asymmetric key established using the server public key with asymmetriccryptography, said symmetric key used to encrypt communications duringthe connection with symmetric cryptography, the method offering analternative for authenticating the server public key, and comprising:transmitting a server certificate from the server to the client, theserver certificate including server public key information; generatingseparate authentication keys by the server and the client, the keysbeing identical as generated using a common secret, said generatingseparate authentication keys including: sending user authenticationinformation from the client to the server; exchanging dynamicinformation between the client and the server; generating a secret bythe client and the server from the response of a strong authenticationtoken; and generating authentication keys at client and server using theuser authentication information, the dynamic information, and thesecret; thereafter generating server authentication information at theserver from data derived from the server public key and processed with asymmetric cryptographic algorithm and the server authentication key;sending said server authentication information to the client; receivingthe server authentication information at the client, and verifying theserver authentication information at the client in order to authenticatethe server public key, said verifying using the client authenticationkey to determine that the server authentication information is based onsaid server authentication key and the server public key informationfrom the server certificate.
 14. A method as recited in claim 13wherein: said generating server authentication information comprisesencrypting data related to the server public key using the serverauthentication key and a symmetric encryption algorithm; said verifyingincludes decrypting the received server authentication information atthe client using a symmetric decryption algorithm and the clientauthentication key; and determining the correctness of the serverauthentication information by comparing the decrypted serverauthentication information with the server public key information fromthe server certificate.
 15. The method of claim 14 wherein the userauthentication information includes a user identification information.16. The method of claim 14 wherein the secure connection is an SSLconnection.
 17. The method of claim 14 wherein the dynamic informationincludes random information.
 18. The method of claim 14 wherein thestrong authentication token includes a challenge- response strongauthentication token, wherein the secret is derived from the response ofthe challenge response token.
 19. The method as recited in claim 14further including: sending encrypted user authentication information tothe server, the user authentication information encrypted by the clientusing the authentication key generated by the client; and receiving anddecrypting the user authentication information by the server, the serverdecrypting the user authentication information using the authenticationkey created by the server, the correctness of the user authenticationinformation verified by the server.
 20. The method of claim 14 whereinthe server certificate transmitted to the client includes the serverpublic key.
 21. The method of claim 14 wherein the server authenticationinformation includes the server public key.
 22. The method of claim 14wherein the server authentication information includes data derived fromthe server public key.
 23. The method of claim 11 wherein the dataderived from the server public key includes a hash of the server publickey.
 24. The method of claim 22 wherein the data derived from the serverpublic key includes a hash of the server public key.
 25. A method forestablishing a secure connection using PKI procedures and authenticatinga server public key, wherein the server public key, obtained from theserver by a client, is used with asymmetric cryptography to establish asymmetric session key for encryption of communications with symmetriccryptography during the connection and offering an alternative forauthenticating the server public key where a server authentication keyis generated by the server and used to create server authenticationinformation for transmission to the client, said method comprisinggenerating a client authentication key by the client, the serverauthentication key and the client authentication key being identical toeach other as both are generated using a common secret; receiving theserver public key in clear text form from the server; receiving theserver authentication information at the client to authenticate theserver public key, the server authentication information including dataderived from the server's public key and processed with a serverauthentication key and with a symmetric cryptographic algorithm; andverifying the server authentication information at the client in orderto authenticate the server public key, said verifying using the clientauthentication key to determine that the server authenticationinformation is based on the server authentication key and the serverpublic key used in establishing the secure connection and received fromthe server.
 26. A method as recited in claim 25 wherein the serverauthentication key is used to encrypt the server authenticationinformation for transmission to the client, wherein said method furtherincludes: decrypting, at the client, the received server authenticationinformation with the client authentication key and a symmetricdecryption algorithm to obtain decrypted data, and wherein saidverifying includes verifying the correctness of the serverauthentication information at the client in order to authenticate theserver public key by comparing the decrypted data with the server publickey used in establishing the secure connection and received from theserver.
 27. The method of claim 26 wherein the server authenticationinformation includes a server certificate.
 28. The method of claim 26wherein the secure connection includes an SSL connection.
 29. The methodof claim 26 wherein the secure connection includes an WTLS connection.30. The method of claim 26 wherein the secure connection includes anIPSEC connection.
 31. The method of claim 26 wherein the secureconnection includes a TLS connection.
 32. The method of claim 26 whereinthe secret is generated by a client strong authentication token.
 33. Themethod as recited in claim 26 which further includes: sending clientinformation to the server to authenticate the client, the clientinformation encrypted by the client using the client authentication key.34. The method of claim 26 wherein the server authentication informationincludes the server public key.
 35. The method of claim 32 wherein thestrong authentication token is a challenge response token, whereingenerating an authentication key by the client includes: receiving achallenge from the server for the strong authentication token;generating a strong authentication token response to the challenge atthe client; and deriving a client authentication key by the client fromthe strong authentication token response.
 36. A method forauthenticating a server public key and establishing a secure connectionbetween a client and a server, the connection formed with PKI proceduresand including a symmetric key, established using the server public keywith asymmetric cryptography, to encrypt communications during theconnection with symmetric cryptography, the method offering analternative for authenticating the server public key, and comprising:receiving a server certificate at the client, the server certificateincluding server public key information in clear text form; generatingan authentication key by the client corresponding to an authenticationkey generated at the server, the keys being identical as generated usinga common secret, said generating an authentication key by the clientincluding: sending user authentication information from the client tothe server; exchanging dynamic information between the client andserver, generating a secret by the client from a response of a clientstrong authentication token corresponding to a secret generated by theserver; and the client generating said authentication key, correspondingto an authentication key generated at the server, using the userauthentication information, the dynamic information, and the secret;thereafter receiving server authentication information at the client,the server authentication information including data derived from theserver public key, processed using the authentication key generated bythe server and a symmetric cryptographic algorithm; and verifying theserver authentication information at the client by using the clientauthentication key to determine that the server authenticationinformation is based on the server authentication key and the serverpublic key information received in clear text form.
 37. A method asrecited in claim 36 wherein; said receiving server authenticationinformation comprises receiving server authentication informationencrypted using the authentication key generated by the server and asymmetric encryption algorithm, and wherein said verifying furthercomprises; decrypting the server authentication information by theclient, the client decrypting the server authentication informationusing a symmetric decryption algorithm and the authentication keycreated by the client, and comparing the decrypted server authenticationinformation at the client with server public key information received inclear text form.
 38. The method of claim 36 wherein the userauthentication information includes a user identification information.39. The method of claim 36 wherein the secure connection is an SSLconnection.
 40. The method of claim 36 wherein the dynamic informationincludes random information.
 41. The method of claim 36 wherein thestrong authentication token includes a challenge-response strongauthentication token, wherein the secret is derived from the response ofthe challenge response token.
 42. The method as recited in claim 36further including: sending encrypted user authentication information tothe server, the user authentication information encrypted by the clientusing the authentication key generated by the client.
 43. The method ofclaim 36 wherein the server certificate received by the client includesthe server public key.
 44. The method of claim 36 wherein the serverauthentication information includes the server public key.
 45. Themethod of claim 26 wherein the data derived from the server public keyincludes a hash of the server public key.
 46. The method of claim 37wherein the data derived from the server public key includes a hash ofthe server public key.